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Abstract 

Despite providing similar functionality, multiple network services may 
require the use of different interfaces to access the functionality, and this 
problem will only get worse with the widespread deployment of ubiqui- 
tous computing environments. One way around this problem is to use 
interface adapters that adapt one interface into another. Chaining these 
adapters allows flexible interface adaptation with fewer adapters, but the 
loss incurred due to imperfect interface adaptation must be considered. 
This paper outlines a matrix-based mathematical basis for analyzing the 
chaining of lossy interface adapters. We also show that the problem of 
finding an optimal interface adapter chain is NP-complete with a reduc- 
tion from 3SAT. 

1 Introduction 

Similar network services can have different interfaces for providing equivalent 
functionality, akin to the way there are a myriad of infrared remote control 
protocols for televisions from different manufacturers. Multiple web services 
running over SOAP [20] may provide different interfaces for the same func- 
tionality, and the same thing can happen for different embedded devices that 
essentially do the same thing. Even the same service from the same provider 
may end up with different interfaces as newer versions are developed [lOj . 

One way to solve the problem of having a myriad of interfaces for the same 
functionality is to standardize on a single interface. This is not always feasible 
due to economical or political considerations, so another way is to develop and 
use adapters that can convert one interface to another [7] . This approach allows 
multiple competing interfaces to coexist without constraining a network client 
to one manufacturer or API standard, which would be required in ubiquitous 
computing environments so as to allow a large number of diverse computing 
devices interoperate with each other seamlessly. 
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The simplest way to adapt an unusable interface into a usable one is to use 
a singe adapter to convert from one to the other. This can easily be extended so 
that multiple adapters are chained to adapt interfaces |15j , which can reduce the 
number of interface adapters that are required. However, it is not always feasible 
for an adapter to perfectly convert one interface to another, since interfaces 
are almost never created with conversion to other interfaces in mind, and the 
problem is only worse when adapters are chained 

This paper outlines a mathematical basis for analyzing lossy interface adap- 
tation through the chaining of interface adapters. In section [3] we describe the 
background behind interface adaptation. Section [3] describes a matrix-based 
mathematical basis for analyzing lossy interface adapter chaining. We show 
that optimal interface adapter chaining is NP-complete in section [4] using our 
mathematical basis, so an exponential-time algorithm for the problem is sug- 
gested in section[5j We discuss related work in section[6l and the paper concludes 
in section [3 



2 Interface adaptation 

In this paper, we take the approach that services that provide similar function- 
ality can be accessed through different interfaces than that used by the service 
itself through the use of pre-existing interface adapters. Each interface is ac- 
cessed through methods, and an interface adapter can provide an alternative 
interface by implementing external methods through the methods available in 
the original interface. This is the same view as taken in pTjFI 

There can be various approaches to creating the interface adapters them- 
selves, from manual development of an adapter to automatic generation through 
semantic or code analysis. While manual development of interface adapters is 
probably the most reliable method, the mathematical framework described in 
this paper does not preclude the use of alternative methods [U HU [21] , and the 
generation of interface adapters themselves is outside the scope of this paper, as 
our mathematical framework assumes a fixed set of interfaces and pre-existing 
interface adapters. 

As a concrete example, we will describe how the web service XWebCheckOut 
could be accessed using the Google Checkout API, an example we based on one 
from [T3] . In figure [TJ we can see how XWebCheckOut has a different interface 
from that of Google Checkout. For a network client that only knows how to 
use the Google Checkout API, it would need an adapter which can convert the 
source interface for XWebCheckOut to the target interface for Google Checkout. 

A developer could implement methods for the Google Checkout interface 
by using methods available in the XWebCheckOut interface. For example, the 
Place-Order method in the Google Checkout interface could be implemented 
using the AddOrder and UpdateOrder methods in the XWebCheckOut in- 

1 Contrary to how we call the original and converted interfaces as source and target in- 
terfaces, respectively, 1111 calls the original and converted interfaces as target and source 
interfaces, respectively. 
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Figure 1: Example of service interface adaptation. 



terface. Doing this for each method in the Google Checkout interface will result 
in an interface adapter that adapts the XWebCheckout interface to the Google 
Checkout interface. 

However, interface adaptation might not be perfect as some methods in the 
target interface simply cannot be implemented using only methods in the source 
interface, resulting in lossy interface adaptation. We can see this in figure [TJ 
where there is no feasible way to implement the New-Order-Notification 
method using only methods available from the XWebCheckOut interface, assum- 
ing that the method cannot be implemented independently of XWebCheckOut. 

Since a network client is using the target interface to access a service, the 
lossiness in the target interface is of more interest than the inability to provide 
access to the full range of functionality provided in the source interface. For 
example, for a network client that only knows how to use the Google Checkout 
API, it is more relevant that an interface adapter may not be able to provide the 
New-Order-Notification method in the Google Checkout interface, rather 
than that the functionality provided by the LoadOrder method in the XWe- 
bCheckOut interface is missing. 

If we require that all available interfaces for similar services must be adapted 
between each other with only a single adapter in between, then the number of 
interface adapters required is in the order of n 2 . Developing all the required 
adapters can be impractical, so interface adapters can be chained to adapt a 
source interface to one interface, this interface adapted to another interface, and 
so on until we get a target interface that a network client knows how to use [15] . 
In the best case, we can even get away with only n adapters given n interfaces. 

However, different chains of interface adapters result in different lossiness 
in the interface adaptation, so we need a way to analyze the chaining of lossy 
interface adapters. We will look at another example in figure [2] where there are 
four interfaces and six interface adapters, each of the latter represented by an 
arrow from the source interface to the target interface it converts from and to. 

Each interface may have the following characteristics: 

• Videol can play both video and audio hies. 

• Video2 can only play video files, but can stop playback, skip over a fixed 
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Figure 2: Multiple interfaces related by interface adapters. 



amount of time, and select captions. 

• VideoS can only play video files, but can get and set the volume and set 
the equalizer for the audio output. 

• Audio can only play video files, but can set audio properties, which are 
the volume and the equalizer. 

And each interface adapter may be implemented as in the following, where 
methods in a target interface not mentioned are not adapted to: 

• The adapter Video ltoVideo2, which converts Videol to Video2, may im- 
plement the play method of Video2 by using the playVideo method of 
Videol. 

• The adapter Video2toVideo3, which converts Video2 to VideoS, may im- 
plement the play method of VideoS by using the play method of Video2. 

• The adapter Video Ito Audio, which converts Videol to Audio, may imple- 
ment the play method of Audio by using the playAudio method of Videol. 

• The adapter AudiotoVideoS, which converts Audio to VideoS, may im- 
plement the setVolume and setEqualizer methods of VideoS by using the 
adjustAudio method of j4M(fio0 

2 While it may seem odd to have an adapter from Audio to VideoS which cannot adapt a 
playback method, it can still be useful when someone wishes to reduce loud noises from an 
audio device with interface Audio using a remote control that only understands the interface 
Video3. 



4 



• The adapter VideoSto Audio, which converts VideoS to Audio, may im- 
plement the adjustAudio method of Audio by using the setVolume and 
setEqualizer methods of VideoS. 

• The adapter VideoStoVideol, which converts VideoS to Videol, may im- 
plement the play Video method of Videol using the play method of VideoS. 

A service with interface Videol may be available, and we may want to 
access it using a client that only understands interface VideoS. There is no 
interface adapter which directly converts interface Videol to VideoS, but there 
are interface adapter chains which can indirectly do the conversion. Chain- 
ing Video ltoVideo2 with Video2toVideo3 or chaining Videolto Audio with Au- 
diotoVideoS can convert interface Videol to VideoS. 

Given multiple possible interface adapter chains, we would want to use the 
best interface adapter chain that can provide the most methods in the target 
interface. Associating a cost with an adapter depending on how well it adapts 
the methods in its target interface and using minimum-cost path algorithms 
such as Dijkstra's algorithm [5] would be an obvious approach to choose the 
best interface adapter chain. However, this naive approach would not work as 
we will see from the example in figure [5J 

Videolto Audio and AudiotoVideoS can adapt one out of two methods in Au- 
dio and VideoS, respectively. In contrast, Video ltoVideo2 and Video2toVideo3 
can adapt one out of four methods in Video2 and VideoS. One might think 
that the Videolto Audio and AudiotoVideoS chain would be better than the 
Video ltoVideo2 and Video2toVideo3 chain simply by looking at how lossy each 
interface adapter is, but one would be wrong. 

AudiotoVideoS requires the adjustAudio method in Audio to implement the 
setVolume and setEqualizer methods in VideoS. However, VideoltoAudio can- 
not implement the adjustAudio method in Audio, so the VideoltoAudio and 
AudiotoVideoS chain ends up with no available methods for VideoS. In con- 
trast, the Video ltoVideo2 and Video2toVideo3 chain can provide the method 
play for VideoS. A single number for each interface adapter cannot express 
such dependencies properly, so we need a more precise approach to analyze the 
lossiness in interface adapter chains. 

In the rest of the paper, we will discuss how to mathematically analyze the 
lossiness incurred from the chaining of interface adapters. We will also assume 
that interface adapters are implemented as transparently as possible: while an 
interface adapter may not be able to provide all of the methods in the target 
interface, the methods it will provide will work just as if they were invoked 
directly on a service having the target interface. 

3 Mathematical basics 

We can start formalizing the problem of lossy interface adaptation by defining 
an interface adapter graph. This is a directed graph where interfaces are nodes 
and adapters are edges. If there are interfaces I\ and I2 with an adapter A that 
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adapts source interface I\ to target interface I2, then Ji and 1% would be nodes 
in the interface adapter graph while A would be a directed edge from 1\ to I 2 ■ 
We do not assume that there can be at most one adapter which can adapt one 
interface to another. This reflects the fact that there can be multiple adapters 
from different developers, similar to how there can be multiple device drivers 
available for a graphics card. It also simplifies some of the arguments, although 
they would still hold even with such a restriction with only minor changes in 
the proofs. 

We will be using a range convention for the index notation used to express 
matrixes and vectors [3J. 

3.1 Method dependencies 

The next step is to formally describe each adapter, i.e. each edge in the interface 
adapter graph, in a way that would be useful for analyzing lossiness. We should 
be able to figure out which methods in the target interface can be provided by an 
interface adapter given the methods available in the source interface. We do this 
by defining a method dependency matrix, a boolean matrix which describes how 
an interface adapter implements methods in the target interface using available 
methods in the source interface. 

The method dependency matrix ciji for an adapter A, where ciji represents 
either the matrix itself or a single component in the matrix depending on the 
context, is defined by how the adapter depends on the availability of a method 
in the source interface in order to implement a method in the target interface. 
ciji is true if and only if method j in the target interface can be implemented 
only if method i in the source interface is available. We denote the method 
dependency matrix associated with an adapter A as depend(A). 

We also define a method availability vector pt for an interface, where each 
component pt is true if and only if method i is available. This boolean vector 
is not intrinsic to an interface, unlike the method dependency matrix which is 
intrinsic to an interface adapter. Instead, it is used to represent the lossiness in 
interface adaptation such that method i in the target interface can be used only 
if Pi is true. For a fully functional service that implements all methods specified 
in its interface, the components of its method availability vector should all be 
true. We denote the number of true components in method availability vector pi 
as \\pi\\, which is equivalent to the Manhatten norm |19j when true and false 
components are replaced by 1 and 0, respectively. 

Given method availability vector pt for a source interface and the method 
dependency matrix aji for an interface adapter, we can derive the method avail- 
ability vector qj for the target interface. A method j in the target interface can 
only be implemented if all of the methods it depends on are available in the 
source interface. So if qj is to be true for fixed j, then all pi must be true when 
aji is true: 




(1) 
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However, equation ([T]) is incomplete in that it does not properly distinguish 
between methods which can always be implemented and methods which cannot 
be implemented given the source interface. For example, a method that returns 
the value of it does not need anything from the source interface, whereas there 
would be no way to implement a video playback method given only a source 
interface specialized exclusively for audio playback. For both cases, all dji are 
false for a specific method j, and equation ([TJ would give the wrong result for 
the latter case. 

This can be worked around by defining a dummy method that is never avail- 
able for every interface. We arbitrarily call this "method 1", so that pi will 
always be false for any method availability vector. It is easy to see that extend- 
ing the definition of the method dependency matrix with the following rules is 
consistent with our definitions and equations for the method dependency matrix 
and method availability vector: 

• an is true, while an is set to false for all i 1. 

• If method j can always be implemented in the target interface, set ctji to 
false for all i. 

• If method j can never be implemented given the source interface, set dji 
to true, while Oj, is set to false for all i ^ 1. 

• If method j depends on the availability of actual methods in the source 
interface, then Oji is false. 

For succintness, we denote a method availability vector for interface / which 
represents that all methods are available, i.e. when the component for the 
dummy method is false while all the other components are true, by lj. 

We also define the operator (g> for a method dependency matrix as applied 
to a method availability vector to represent the operation in equation ([T]) , or in 
other words: 



It is easy to sec that a square boolean matrix where the diagonals are true 
and the rest of the components are false is an identity matrix for the adaptation 
operator ®. We denote an identity matrix with n rows as I„. 

3.2 Adapter composition 

To analyze the chaining of lossy interface adapters, we are also interested in 
how to derive a composite method dependency matrix from the composition of 
two method dependency matrixes, which would be equivalent to describing the 
chaining of two interface adapters as if they were a single interface adapter. 

Given interfaces I±, I2, and I3, let the corresponding method availability 
vectors be pi, qj, and r^. In addition, let there be interface adapters Ai and A2, 
where Ai converts I\ to I2 and A2 converts I2 to -Z3, with corresponding method 




(2) 
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dependency matrixes and bkj, respectively. We would like to know how to 
derive the method dependency matrix that would correspond to an interface 
adapter equivalent to A\ and A2 chained together. 
From equation (|T|) and our assumptions: 

3 

= A v A(" a ^ 
= A A^kj v -.aji v 

3 i 

= A A^ b ^ v v 

i 3 

= A (AHy v ^*) v ^ 

= A \f( bk 3 Aaji) Vpi 
* V 3 

We reuse the operator ® to represent the composition of two method depen- 
dency matrixes, and by comparing the above with equation ([1}, we can define 
it as: 

bkj ® aji = \f(b kj A aji) (3) 
3 

l n from section 13.11 is also an identity matrix for the method dependency 
matrix composition operator (g). 

The C3> operator is "associative"^ when applied to method dependency ma- 
trixes and a method availability vector, i.e. bkj ® (aji ®Pi) = (bkj <8> aji) ® Pi, 
which shows that in terms of lossiness, chaining adapters and then applying it 
to a source interface is equivalent to applying each adapter one by one to the 
source interface: 

b k j ® (aji ®pi) = A ^hj V A(~ ,a J' 1 v P*)J 

= A A^ bk <> v ~ na i i v p ^ 

3 i 

= f\ f\(^b k j V ^a 3 i V p t ) 

i 3 



3 It is not technically associative in this context as the ® operator as applied to method 
dependency matrixes is not really the same as the CS> operator as applied to a method depen- 
dency matrix and a method availability vector, similarly to how X for numbers is different 
from X for sets. 
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= AAH 6 « Aa a) vw) 
* j 

= /\ \ f\^(bkj A aji) \/ pi 
i \ j 

» \ j 

= {bkj ® a oi ) ® pi 
Likewise, method dependency matrix composition is associative: 

cik ® (&fcj ® dji) = \J \ Q fe A \/(&fej A a ji) 
k \ 3 

= \J\J(cik Ab k j Aaji) 
k j 

= y\J(cik Ab kj Aa^) 



j k 

b k j) A dji) 

{cik ® b k j) ® 



= \J\\/{cikAbk 

j \ k 



However, method dependency matrix composition is not commutative, as 
can be easily seen by considering the composition of method dependency ma- 
trixes that are not square matrixes. 

We can also formalize the somewhat vague intuition that a longer interface 
adapter chain is worse in terms of lossiness. If A\ and A2 are interface adapters, 
where A\ converts I\ to 1% and Ai converts 1% to J3, with aji = depend (Ai) and 
bkj = depend^A^i) in which an and b\\ are both true as in section f3. 11 then for 
Pi = b kj ® lj 2 and p' t = b k j ® aji ® 1^ : 

Pfe = H*i V /) A /\ (-.6jy V t) = -.6 M 
j¥1 



p'fe = A ( -*« v I v /) A A v *) 

mi 



f\(-ib k j V -.aji) 

^fefei A f\(-ib k j VOj-i) 
j¥1 
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Figure 3: Interface adapter graph for figured] 



■ ■■P'k^Pk (4) 

With I\ and 1% being the source interfaces for the interface adapters that 
aji and bkj represent, respectively, we can also infer from equation (j4|) that 

\\h 3 ®l'i 2 \\ > \\b k j ®aji®l' h || (5) 

which, along with the associativity of method dependency matrix composition, 
formalizes the notion that extending an interface adapter chain is worse in terms 
of lossiness. 

The definitions of the method dependency matrix and the method availabil- 
ity vector in section [3~T| along with the associativity rules proven in this section, 
provide a succinct way to mathematically express and analyze the chaining of 
lossy interface adapters. 

3.3 An example 

As an example, we apply the mathematical framework to the interfaces and 
adapters in figure O We will denote interfaces Video 1, Video2, Video3, and 
Audio as I\, I2, I3, and I4, respectively, while A±, A2, A3, A4, A5, and Aq 
denote the interface adapters Video ltoVideo2, Video 2to Video 3, Video Ito Audio, 
AudiotoVideo3, VideoSto Audio, and VideoStoVideol, respectively. We also in- 
dex each method in the order they appear in figure [2] along with an extra dummy 
method with index 1, and let a k ^ — depend (A^)- Figure [2] is already an interface 
adapter graph, which is simplified and labeled in figure [3] 
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Some method dependency matrixes would be: 



ft f f\ 
f t f 

t f f 

t f f 

V * / / J 

( t f f f f\ 
f t f f f 
t f f f f 
t f f f f 
V t f f f f j 

t f f f I 
t f f f f 
f f f t t 



Given a fully functional service which conforms to interface Video 1, we would 
expect that only the play method would be available for interface VideoS after 
going through the adapter chain A\ and Ai , which can be verified by computing 
the method availability vector a\ - ® aj { ® l' Ti : 

a 2 kj ® a),® l' h = [f,tj,fj] 

One can also verify the following by hand, which would be expected from 
the associativity of ®. Associativity can be very useful in developing algorithms 
analyzing chains of lossy interface adapters, since fragments of an interface 
adapter chain can be assembled independently and still give the same method 
dependency matrix for the whole chain. 

af k «) a% <g> a)i (8 l' h 

= a?fc®(ay®(Oii® 1 /i)) 
- {(afk ® 4j) ® ® 1/, 
= (4 ® a? kj ) ® (a), ® 
= [/,/,/] 

We can also verify the following, which is consistent with equations (j4]) and 
(0 , and is in line with the intuition that extending an adapter chain can only be 
worse in terms of lossiness, although this does not mean that a longer adapter 
chain is always worse than a shorter adapter chain. 



affc ® a 2 



af k ® l/ 3 
l/ 2 



[/, /, /] 
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Figure 4: General form of a boolean expression reduced to an interface adapter 
graph. 

4 Optimal adapter chaining 

One of the things that could be hoped from the mathematical framework in 
section [3] is that it could help with the development of an efficient algorithm for 
optaining an optimal interface adapter chain from an actual service to a target 
interface that incurs the least loss in terms of functionality. Unfortunately, the 
problem is NP-complete, as will be shown in this section, dashing hopes for such 
an algorithm. 

First, we must formally describe the problem, which we will call CHAIN. Let 
us have an interface adapter graph ({h}, {Ai}), where {Ii} is the set of interfaces 
and {Ai} is the set of interface adapters. Let a k be the method dependency 
matrix associated with adapter Ak- Let S € {Ii} be the source interface and 
T G {Ii} be the target interface. Then the problem is whether there is an 
interface adapter chain [Ap^, Ap^), ■ ■ ■ ,Ap(m)} such that the source of Apm 
is S, the target of A P(m) is T, and ||u T || = ||a p ( m ) ® • • • <g> a p ^ <g> a p W <g iy 
is at least as large as some parameter N. 

Informally, this is an optimization problem which tries to maximize the 
number of methods that can be used in a fixed target interface, obtained by 
applying an interface adapter chain on a fully-functional service which conforms 
to the source interface. We show that the problem is NP-complctc by reducing 
3SAT [5] to CHAIN. 

Based on the conjunctive normal form of a boolean expression E with exactly 
3 literals in each clause, we will construct an interface adapter graph G in three 
parts and the corresponding method dependency matrixes. One part will model 
the setting of each variable to true or false, another part will model the value 
of each clause once the variable values are set, and the last part will serve as a 
filter so that E is satisfiable if and only if there is a chain in G such that ||w T || 
equals the number of clauses in E. 

Figure |4] shows what a reduction from an instance of 3SAT to an instance 
of CHAIN would generally look like. 
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4.1 Representing values 

We will represent values of literals and clauses using the method availability vec- 
tor for each interface, where all but one of the nodes in the constructed interface 
adapter graph will contain the same set of methods. At certain points in the 
interface adapter graph, a true or false component in the method availability 
vector would directly map to the value of a literal or a clause. 

For almost all nodes, including the source, the set of methods will be fixed 
with one dummy method, one method for each clause, and one method for 
each literal, so almost all method dependency matrixes will be square matrixes. 
As the method dependency matrixes will have large parts in common with the 
identity matrix, we will only be mentioning how each matrix differs from the 
identity matrix. 

Each method will be labeled as follows: 

• The dummy method will be labeled d. 

• For each clause Ci, the method will be labeled Ci. 

• For each variable Vi, the method for the variable itself will be labeled U, 
while the method for the negation of the variable will be labeled k . 

There is a single method dependency matrix used in the filter part of the 
graph that will not be a square matrix. 

4.2 Handling literals 

The basic approach of this part of the graph, which we will call the variable 
handling subgraph, is to set the value for each variable depending on which 
adapters are chosen to be included in the chain. For each variable Vi , v-i , . . . , 
v v , we define nodes V\, V2, ■ . ■ , V v , and we let Vo = S. Between each Vi-i and 
Vi, we define two adapters which will leave everything about the method avail- 
ability vector unchanged from one node to the next except for the components 
corresponding to the literals for Vi. One will make the variable effectively true, 
while the other will make the variable effectively false. 

For each Vi for i > 0, we will define a positive literal adapter with 
method dependency matrix a li and a negative literal adapter Aj- with method 

dependency matrix a li . For the positive literal adapter, a^.- is false for all j, 
Oj- d is true, and a|i is false for all j other than d. Similarly for the negative 

literal adapter, ah. is false for all j, aj* d is true, and ajv is false for all j other 
than d. 

It should then be easy to see that for a method availability vector pi with 
a false pd, all components of a li ® Pi should be the same as pi except for the 
components corresponding to Zj and Zj, which will be true and false, respectively. 
Likewise, all components of a li ® pi should be the same as pi except for the 
components corresponding to Z, and k, which will be false and true, respectively. 
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Figure 5: Choosing a variable assignment. 

The rest of the interface adapter graph will be the descendant of V v , so any 
adapter chain from S to T must go through all of Vo, Vi, . . . , V v in order, and 
for every variable one and only one of the positive literal adapter or the negative 
literal adapter must be chosen as in figure [S] due to the structure of the variable 
handling subgraph. This is equivalent to choosing a variable assignment, and 
at V v , the method availability vector pi will be such that for each variable Vi, 
Pl t and pj- will have opposite values, so that it would be the same as setting the 
value of Vi to pi i . 

4.3 Handling clauses 

Based on the variable assignment that is taken care of by the variable handling 
subgraph in section I4.2[ this part of the graph, which we will call the clause 
handling subgraph, is responsible for determining the value of each clause. 

In order to model disjunction, not only do we define a node Ci for each 
clause Ci, we also define three subnodes CV, , for j from 1 to 3, for each of the 
literals in the clause. These nodes are separate from those defined in section l4~2l 
The idea is that if any of the literals are true, then at least one of the nodes will 
end up with a method availability vector marking the clause as true, so we can 
use this to mark the same for Ci itself. We also set Cq = V v for convenience of 
notation, and c will be the number of clauses. 

For each clause Ci, there are edges from Ci_i to each of the subnodes Cy, 
and in turn there are edges from each subnode Cy to Ci. So there will be three 
alternate paths from Ci-\ to Ci. 

For edge (C,-_i, Cy), if I corresponds to the literal for Cy, the method de- 
pendency matrix a for the edge is defined by setting a Ci i to true and a Ci k to false 
for all k other than I. Then it should be easy to see that a <E) p is the same as 
the method availability vector p except for the component p Ci , which would be 
true if and only if p\ is also true. For edge (Cy, Ci), the corresponding method 
dependency matrix is simply the identity matrix. 

If clause Ci is true, then one of the literals must be true. Then the path 
through the subnode Cy for the true literal will result in a true component for 
the clause in the method availability vector at C,; . If the clause is not true, then 
the same component will be false no matter the path taken, since it will be false 
for all subnodes Cy. 

T will be the descendant of C c , and since the source is in the variable han- 
dling subgraph, which is only connected to the clause handling subgraph by Co, 
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Figure 6: Disjunction through alternate paths. 

any interface adapter chain from S to T must go through each of the nodes 
Co, Ci, . . . , C c in order as in figure |H And if all clauses are true with the 
variable assignment done in the variable handling subgraph, which is equivalent 
to choosing which adapters to include from the subgraph, only then will there 
be a path from Co to C c which will result in true components for all clauses in 
the method availability vector at C c . 

4.4 Filtering 

The last part of the constructed interface adapter graph is the filtering part, 
which discards all methods corresponding to literals from the method availability 
vector so that only the dummy method and methods corresponding to clauses 
remain. 

The filtering subgraph is made up of only two nodes and a single edge. 
One of the nodes is the target T, and its interface only contains the dummy 
method and all the methods corresponding to clauses. The other node is C c 
from section |4~51 The (c + 1) x (2v + c + 1) method dependency matrix aji for 
the edge from C c to T defined as follows accomplishes the filtering: 

• For all clauses c$, a CiCi is true. 

• For the dummy method, add is true. 

• All other compenents are false. 

4.5 Analysis of the reduction 

The constructed interface adapter graph has v + 4c + 2 nodes and 2v + 6c + 
1 edges, where v is the number of variables and c is the number of clauses. Also, 
each method dependency matrix has at most (1 + c + 2v) 2 components, so the 
reduction of a candidate for 3SAT to a candidate for CHAIN can be done in 
polynomial time. So we just need to verify that there is a positive answer for 
CHAIN with N = c if and only if there is a positive answer for 3SAT. 

If the boolean expression is satisfiable, then there is a variable assignment 
that makes it true. Consider the following interface adapter chain. In the 
variable handling subgraph, include edges that correspond to the variable as- 
signment. In the clause handling subgraph, there is guaranteed to be a path 
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where all components corresponding to clauses in the method availability vec- 
tor at the target end up being true, given the path in the variable handling 
subgraph, so use this path in the chain. Then ||u T || will be exactly c. 

Conversely, suppose there is an adapter chain such that ||w T || = c. Then 
assigning values to variables according to the path through the variable handling 
subgraph results in a satisfying variable assignment for the boolean expression. 
This is because the clause handling subgraph and the fact that ||u T || — c together 
imply that all clauses are true for the derived variable assignment. And given 
an arbitrary interface adapter chain and an optimal chain, it is easy to verify 
whether the arbitrary adapter chain is not optimal, so CHAIN is NP-complete. 

5 A greedy algorithm 

As shown in section [H the problem of finding an optimal interface adapter 
chain that would make available the most methods in the target interface is an 
NP-complete problem. Short of developing a polynomial-time algorithm for an 
NP-complete problem, practical systems will have to use a heuristic algorithm 
or an exponential-time algorithm with reasonable performance in practice. 

Algorithm [T] is a greedy algorithm that finds an optimal interface adapter 
chain between a given source interface and a target interface. Given an interface 
adapter graph G, it works by looking at every possible acyclic adapter chain with 
an arbitrary source that results in the target interface t in order of increasing 
loss, taking advantage of equation ([5]), until we find a chain that starts with the 
desired source interface s. In this context, loss means the number of methods 
unavailable in the target interface given a fully functional service with the source 
interface, which is computed in algorithm [2J so the algorithm is guaranteed 
to find the optimal interface adapter chain. In the worst case, however, the 
algorithm takes exponential time since there can be an exponential number of 
acyclic chains in an interface adapter graph. 

While algorithm [1] may take exponential time in the worst case, results with 
a similar algorithm from |llj based on a small randomly generated interface 
adapter graph suggest that the greedy algorithm has acceptable performance in 
practice. 

Algorithm Q] can easily be extended to support the selection of an optimal 
source interface with weights associated with methods expressing their impor- 
tance as in algorithm [3J This can be done by checking that the starting point of 
an interface adapter chain is included in a set of possible source interfaces, in- 
stead of just comparing it to a single source interface, and summing the weights 
for the available methods in the target interface as in algorithm [4] and using 
equation (j4]), instead of just counting the methods. 

Unlike algorithm[TJ which would find an interface adapter chain after a single 
service was presumably found by a service discovery process, algorithm [3] can 
be used in the service discovery process itself to search for the best service, not 
just in terms of what is required from the service, but also considering how 
well the client could use the service. And by weighting the methods in the 
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Algorithm 1 A greedy algorithm for interface adapter chaining. 



procedure Greedy-Chain(G = (V,E), s, t) 

C <— { [] } > chains to extend 

M = > discarded chains 

D ^— {[] ^ Idim(i')} > method dependency matrixes 

while C ^ do * 

c <— element of C minimizing Loss(c, D) 
if c ^ [] A sowrce(c[l]) = s then 
return c 

else if no acyclic chain not in C U M extends c then 

C <-C-{c} 

M <- M U {c} 
else 

if c = [] then 

5 <- {[e] \ e G E, target(e) = t} 

else 

B <— {e : c | e e E, target(e) = source(c[l])} 
end if 

remove cyclic chains from B 
C <- C U B 

D 4- D U {e : c i-> D[c] ® depend(e) \e:cEB} 
end if 
end while 
end procedure 



Algorithm 2 Computing the lossiness of an interface adapter chain, 
function Loss(c, D) 
s 4— source(c[l]) 
t 4- target (c[\c\}) 
return dim(lj) - \\D[c] ® l'J 
end function 
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Algorithm 3 Greedy discovery for weighted interface adapter chaining. 



procedure Greedy-Chain(G = (V,E), S, t, W) 

C <— { [] } > chains to extend 

M = > discarded chains 

D {[] >-> Idim(i')} > method dependency matrixes 

while C^do' 

c element of C maximizing Weight(c, D, W) 
if c ^ [] A soitrce(c[l]) G 5 then 

return (source(c[l\) , c) 
else if no acyclic chain not in C U M extends c then 
C^C*-'{c} 
M <- M U {c} 
else 

if c = [] then 

£? <r- {[e] | e e E, target(e) = t} 
else 

B <— {e : c | e £ £7, target (e) = source (c[l])} 
end if 

remove cyclic chains from B 
C <- CUB 

D <- D U {e : c i-> D[c] ® depend(e) \ e: ce B} 
end if 
end while 
end procedure 



Algorithm 4 Computing the weight of an interface adapter chain, 
function Weight(c, D,W = tUj) 
s <— source (c[l]) 
f <— targef (c[|c|]) 
Pi <- D[c] ® l' s 
return Wi 
end function 
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target interface, it can take into account the importance of each method. By 
having sufficiently large weights for essential methods compared to those of non- 
essential methods, algorithm [3] can also guarantee that an adapter chain which 
makes all essential methods available will always be preferred over those which 
do not. 

6 Related work 

The mathematics in this paper was motivated by the interface adapter frame- 
work [11] used by the Active Surroundings middleware for ubiquitous computing 
environments |12) . In order to support a transparent computing experience de- 
spite a user moving around locations where similar services may have different 
interfaces, the framework uses interface adapters to adapt interfaces. [TT] de- 
fines the problem informally and shows the effectiveness of a greedy algorithm 
based on uniform cost search [IB] , 

Other work have also used interface adapters to resolve service interface 
mismatches. Some attempt to aid developers create interface adapters using 
template-based approaches [1] [14] or mapping specifications [21] . Others reduce 
the number of required interface adapters by chaining them together [15j , while 
others use a chain of interface adapters to provide backwards compatibility as 
interfaces evolve [9] [TU] ■ These chaining approaches ignore that one chain may 
be worse than others in terms of lossiness. 

Analyzing the chaining of lossy interface adapters is in many ways similar 
to depedency analysis in software architecture [5] [T3] [S] [TB] . These are designed 
to support maintenance of large software systems and usually consider a lossy 
connection between software components to be the exception and not the norm. 
Techniques used in software architecture such as code analysis [T7] or fault 
injection [2] could also be the basis for deriving the method dependency matrixes 
for interface adapters. 

7 Conclusions 

By chaining a series of interface adapters, it is possible for a single-interface 
client use a much wider variety of services with heterogeneous interfaces without 
requiring an explosive number of interface adapters. However, as an interface 
adapter may not be able to convert one interface to another perfectly, we have 
developed a mathematical framework which can be used to analyze the lossiness 
incurred during chained interface adaptation. 

The mathematical framework defines the method dependency matrix, the 
method availability vector, and the composition operation for describing the 
properties of composed adapters, which was also proved to be associative. The 
framework could be used to analyze the lossiness in interface adapter chains and 
develop algorithms for finding such chains. 
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However, finding an optimal interface adapter chain is an NP-complete prob- 
lem, which can be proven by reducing 3SAT to CHAIN. A greedy algorithm for 
finding an optimal interface adapter chain requiring exponential time in the 
worst case was suggested. 

This paper has only considered the all-or-nothing case where a method in 
a target interface can be completely implemented using methods in the source 
interface. However, in certain cases the method could only be implemented 
partially. One possible extension to the mathematical framework is to con- 
sider partial adaptation of such methods. Extending it so that it can analyze 
the lossiness when services are composed is another possibility. Heuristic al- 
gorithms with provable approximation bounds is another topic that would be 
worth looking into in the future. 
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